Filter by Brand Clear Filter
28 Sep 2023

Experimentation at Delivery Hero is Fun with Flags

We unveil the story behind Fun With Flags (FwF),  our Experimentation Platform at Delivery Hero. Learn how FwF moved from a feature-flagging tool to an experimentation platform, influencing strategic decisions across the organization. Read the article to get a glimpse of where we started and where we are going.

by | Berlin

03 Feb 2023

How to Turn Stakeholders into UX Advocates: A Guide For Any UX designer & researcher

Stakeholders often perceive the UX as a time-consuming & skippable process. “We already know XYZ. We don’t have time to afford to do research. Is insight from 5 users really trustworthy? 

As a UX practitioner, you know that gaining buy-in from stakeholders is essential to the success of your projects. But what if they’re not already sold on the value of UX design? Recently, we had a project that started with doubts from stakeholders but ended with a team full of UX advocates. 

In this post, we would like to share the lessons and tips we’ve learned from our recent project.  


1. Make the business case for the design and welcome all the questions

Your stakeholders may need to be more familiar with the value of design, so it’s essential to make a case for why it’s vital to the success of your project. Explain how design can help to improve the user experience, increase conversion rates, and drive business results. Use examples and goals that are valuable for them, and start these conversations early – before the project kicks off.

Remember – no one challenges without reason. Understanding the ‘whys’ of the main stakeholders will help you to uncover what business goals and metrics are the most important to them. Above all, you will have an insight into their worries. Equipped with this knowledge, you can create a design and research plan that mitigates their worries and shows how design can impact the metrics and goals they care about.

(Tips) How we did it:

  • In the planning stage, give two or three options for a design plan with connected risks and benefits (as an example: one plan with the user research and one without). This way it will be easier for the stakeholder to choose a way forward.
  • Align clear goals from the get-go. Make sure that terms and definitions mean the same for all team members.

2. Get them involved early to build trust

The best way to get stakeholders on board with your project is to involve them from the outset. Invite them to participate in user research, help to define the project goals, and provide feedback on early designs. Getting them involved early will help them understand the value of design and build trust.

It will take time and effort to build a relationship founded on trust, sometimes maybe even as long as 6 or more months. However, such a relationship is a crucial puzzle piece to a successful designer and stakeholder long-term collaboration. If stakeholders trust you in your decision-making, you can move to strategic work more quickly.

(Tips) How you can do it:

  • Make them feel heard online and offline 
  • Prioritise challenges and ideas together
  • Create one communications channel (perhaps a Slack channel?)
  • Keep them regularly updated on the progress (if you have a chance – over-communicate)
  • Don’t omit chances for social interactions so that they get to know you as a person, not just “another UX designer in a company x”

3. Work together through all highs and lows

Another key element you need is collaboration. Collaboration is a great way to create a sense of ownership and alignment throughout the project.

People are always in favor of their own ideas. Especially the stakeholders, who have their stakes in this project would appreciate making their own decisions. Helping them to feel this sense of ownership – making decisions with the information has helped us turn them into the biggest research advocates.

Surprises can be good. It can be a game changer. But it should come at the right time. It can come while we run the interviews and tests and uncover the surprising findings. But once they are uncovered, the earlier you share with the stakeholders and get aligned, the better. Collaboration can be a great way to get this alignment as early as you can.

(Tips) How you can do it:

  • Get stakeholders to observe the sessions
  • Hold daily debrief sessions to gather their observations & insights
  • Hold collaborative analysis sessions to incorporate their perspectives and insights into the final analysis
  • Make sure you educate the research principles along the way rather than taking their literal words into the report

4. Don’t jump into solutions too early

We instinctively want to fix problems quickly. Especially when they are clearly spelt out in a research readout presentation. However, as designers, we are there to remind everyone of the power of discovering and agreeing on the problem first.

It might feel counterintuitive to the stakeholders to spend a large chunk of time on the challenge rather than start discussing solutions. However, this will help to ensure that you are solving an actual problem, rather than a symptom of the problem and that all angles are being taken into account.

(Tips) How you can do it:

  • Have minutes after the meeting so that you don’t lose track of what you spoke about
  • Invite them to a pre-read of the user research sharing session, so that they are aware of what to expect
  • Assure that there will be enough time to co-create solutions later

5. Build empathy with the stakeholders as much as you do with the users

It’s essential to make it feel for stakeholders that they are a vital part of the design-led project. Especially, because they are! Set up regular check-ins, listen actively and be open to any changes to the project plan. This will help to ensure that they feel invested in the project and that their feedback is being taken into account.

(Tips) How you can do it:

  • Organise stakeholder interviews prior to the sprint 0 kickoffs
  • Be proactive about following up—help make reviews easier for others
  • Understand and remember their perspective while designing

Conclusion

There are a few key steps to take when trying to transform stakeholders into design advocates. First, it is important to clearly articulate the value of design and how it can help achieve business goals. Next, it is necessary to build trust with stakeholders by being transparent and honest about the design process. Finally, it is crucial to involve stakeholders in the design process as much as possible and get their feedback before making any final decisions. By taking these steps, you can help all stakeholders see the value in design and become advocates for the design process.

by Justyna Belkevic, Dahee Kang | Berlin

26 Nov 2021

Client Foundation: Celebrating one year together as a Platform Team

Delivery Hero has seen several years of sustained, rapid growth – with customers, orders and revenues doubling almost every year. Our Tech & Product teams have grown in lockstep, with the Consumer Tech and Product organisation growing to now over 1,000 people.  A diverse collection of developers, designers, analysts, product managers, along with other specialist roles across the world, helping to create a digital product used by customers from Tokyo to Oslo. 

However, growing isn’t scaling. As we get larger, how we build our products changes. What worked at 1x doesn’t work at 5x, and certainly not at 10x. Alongside our Experience Teams responsible for products such as vendor discovery, checkout and subscriptions – we have platform teams acting as enablers.

The Client Foundation tribe was a year old on the 18th of November (Happy Birthday to us 🥳), and was founded to enable scale from that growth. The tribe is accountable for two main domains:

  • Developer & Designer Experience.
  • Foundational Topics such Speed, Reliability, UX Coherence, and Accessibility.

I want to share with you some of the unique aspects of our tribe that have led to our success, some of the projects that we’re working on, and a bit more about the tribe itself and the amazing teams that make it.

Our tribe is made up of 8 teams exploring these domains:

  • Frontend (Web) Infrastructure
  • Communications Infra
  • Quality Automation Infra
  • App Developer Experience
  • App Performance & Reliability
  • App Product Marketing
  • Accessibility
  • Design Engineering

Developer & Designer Experience

With this domain, we focus on abstracting the underlying complexity of our product and the architecture, in order to enable our colleagues to focus on what matters most – creating high value, high quality, and high performing products for our customers. There are overlaps with Google SRE’s concept of toil, but we’re also exploring how we improve knowledge sharing, flow, productivity and collaboration for our teams.

Think about all those times you’ve been frustrated when building a product – the build pipeline is slow (you can make lunch it takes so long), you have built something that isn’t core to your team’s mission but you need it as an enabler, such as interfacing with message gateways (SMS, push, email). These are all context – they help you get the job done, but if 5 or 10 teams are doing this independently, there is a lot of repeat work for an organisation. Or, perhaps, struggling to know the best way to write (and store) documentation for your product. The things that get in the way of their team’s core mission are the problems our teams are addressing. 

Foundational Topics

These are themes and metrics of how we all build products together. Topics like speed, reliability, ux coherence and accessibility. All our teams at Delivery Hero are responsible for these, but the teams in Client Foundation take accountability. This doesn’t mean we are making changes to improve speed itself, or fixing accessibility issues (sometimes we do). Instead, we  partner with other squads on understanding different issues and their impact, provide tooling and observability, and create the means for the Experience Teams to identify these issues before they affect our customers. They help teams understand all performance topics.

Applying Product Development to Platform Teams

Ultimately, the core of Product Development is the same whether you’re building for end consumers, other businesses, or internal users. It is about understanding the opportunities and problems of your users and identifying (possible) ways to solve them. We believe in applying this mindset to our platform challenges to help us create great products.

Platform Product Development has been an increasingly common trend in the industry. 

More and more companies are building internal platforms to roll out new digital solutions efficiently. Companies that succeed with this strategy are applying [Product Development practices] to internal platforms.This means establishing empathy with internal consumers (the development teams) and collaborating with them on the design.

Platform product [development] creates roadmaps and ensures the platform delivers value to the business and enhances the developer experience

Thoughtworks Tech Radar (Vol. 22)

Unfortunately, we’re also seeing less successful approaches, where teams create a platform in the void, based on unverified assumptions and without internal customers. These platforms, often despite aggressive internal tactics, end up being underutilized and a drain on the organization’s delivery capability. As usual, good product [development] is all about building products that [users] love.

Thoughtworks Tech Radar (Vol. 22)

Product and Tech work together on these problems. All the teams in Client Foundations are cross-functional. The intention is these teams have all the skills they need to go and explore their opportunities. Our App Engineering experience team, for example, has iOS and Android developers – along with a Product Manager, Product Analyst and User Researcher. Soon, we’ll add Technical Writers to the team. This collection of people work together to understand the drivers of a great developer experience, and identify ways to improve it.

Data-informed Decisions in Platform Teams

Data is key to making informed decisions. It helps break biases and illuminates opportunities and sparks ideas we may not have otherwise been aware of. Much like a consumer-facing team, the platform teams of Client Foundation leverage both qualitative and quantitative insights to build better products. Our tribe has a dedicated User Researcher (with plans for 2 more!) helping us gain insights through a mix of sources, such as  developer interviews, surveys, and usability testing. 

Alongside User Research, our growing Product Analytics team works as integral parts of the squads to track our products with metrics, understand relationships in the data, and measure impact. These can be things affecting our Lead-time-to-Change, or correlations between our app startup speed and conversation rate. Help us, our colleagues and our organisation, understand where we can be of  most value. This has provided interesting learnings for us – for example, although we had built extensive analytics infrastructure around our end-user behaviour,our end-to-end visibility of the developer experience was non-existent, and something we’ve built-out  from scratch.

Some of our projects

Over the past year, our teams have worked on many initiatives to advance our mission. Below, we’ve outlined a handful of them.

In the realm of Developer Experience, one of the biggest pain points our colleagues were facing was around the Build Pipeline. CI (Continuous Integration) was the clear winner of the unenviable award ‘worst part of the development experience’ for all of our client developers. This was identified through our Developer & Designer Quarterly Experience survey, and through our User (Developer) Interviews. During Q2 and Q3, the explored multiple avenues to optimise this – including our introduction of our mock-server and better caching of (our extensive) translations. 

As a result of this work, we’ve reduced the total wait time for our developers by a total of 450 hours per week (approximately 40% faster). Although we’re still a way from our goal of, “your build is ready before your coffee”, we’re excited to see the improvements for our colleagues.

The core of our business is food delivery and our motto is always delivering an amazing experience. This should be for everyone. Performance & Reliability is a key focus for us with users all over the world with a range of devices – from the iPhone SE running iOS11 in Helsinki on a 2G connection, to the latest Samsung Galaxy running corporate wifi in Taiwan. We’re constantly looking for ways to give everyone the best possible experience. Some things are universal – people don’t want to wait for a faster app. Time-to-interactive benefits everyone, but other topics are more challenging. Images are important when picking your meals, so image optimisation (quality vs size) gets a little more complicated. 

Our Bento Design System has been growing from the smallest atoms, gaining widespread adoption. One of our unique challenges is that our design system has to support multiple brands (foodpanda, foodora, mjam, to name but a few). The system started as a grass-roots movement from a number of key advocates and was identified as a key enabler to help our teams move faster and build a more coherent UI/UX for our customers. Now, a fully dedicated team, they continue to deliver and delight by improving the flexibility of the system and introducing exciting elements, such as micro-interactions and animations into the system.

What’s next

We’re continuing to invest heavily in the scope of the Client Foundation group. One of our priorities is building strong analytics foundations to better understand the developer experience as connecting technical performance data with end business impact. We are also growing our teams, equipping us with the right skills and experience to tackle the challenges a rapidly growing company faces. 

I hope we’ve given you a bit of insight into our tribe, how we operate, and shared some of the things we’re proud of.  If you’re the type of person excited by the topics we take on, view our open roles or join our Talent Community to stay up to date with what’s going on at Delivery Hero and receive job alerts.


About the Author

Curtis is the Director of Product for the Client Foundation Tribe, focused on enabling the organisation not just to grow, but to scale. He joined Delivery Hero in 2019 as the Product Manager for the App Homescreen and is a self-professed product geek. Outside of work, he enjoys running, rugby and board games.

by Curtis Stanier | Berlin

25 May 2021

Our 5 biggest learnings from a redesign

How we redesigned our vendor-facing application “Go” and what we learned along the way.

At the end of 2019, our design team started the redesign of our vendor-facing application called Go. Our vendors use Go mainly for order processing and its supporting functionalities (e.g. inventory management, schedules, etc). 

When our design team began the redesign project, we had several issues we needed to overcome. However, the biggest one was to get a clear understanding of the application (as it was built way before my colleagues and I joined Delivery Hero). We also needed to understand its usage, user needs, and what we should expect during a redesign. Below I explain the biggest learnings we made along the way.

by Wioleta Maj | Berlin

15 Dec 2020

TEDW — A simple model for asking better questions.

Asking better questions is an extremely important skill. Much of what we do depends on building a good understanding to make better decisions. A good decision is one that doesn’t need changing (Shishir Mehrotra, 20VC) and those decisions are usually only made when there is a common understanding with those involved. So how do we build that understanding?

by Curtis Stanier | Berlin